[Chapter 10] 10.12 Load Sharing Between Mirrored Servers
Author: Cricket Liu & Paul Albitz
Date: 1999-01-06T18:37:15Z

#

| Chapter 10 Advanced Features and Security |

## 10.12 Load Sharing Between Mirrored Servers

Name servers released since BIND 4.9 have formalized some load-sharing functionality that has existed in patches to BIND for some time. Bryan Beecher wrote patches to BIND 4.8.3 to implement what he called "shuffle address records." These were address records of a special type that the name server rotated between responses. For example, if the domain name foo.bar.baz had three "shuffled" IP addresses, 192.1.1.1, 192.1.1.2, and 192.1.1.3, an appropriately patched name server would give them out first in the order:

>     192.1.1.1 192.1.1.2 192.1.1.3

then in the order:

>     192.1.1.2 192.1.1.3 192.1.1.1

and then in the order:

>     192.1.1.3 192.1.1.1 192.1.1.2

before starting over again with the first order, and repeating the rotation ad infinitum.

The functionality is enormously useful if you have a number of equivalent network resources, like mirrored FTP servers, Web servers, or terminal servers, and you'd like to spread the load among them. You establish one domain name that refers to the group of resources, configure clients to access that domain name, and the name server inverse-multiplexes the accesses between the IP addresses you list.

BIND 4.9 and later versions do away with the shuffle address record as a separate record type, subject to special handling. Instead, a modern name server rotates addresses for any domain name that has more than one A record. (In fact, the name server will rotate any type of record, except PTR records, as long as a given domain name has more than one of them.) So the records:

>     foo.bar.baz.    60    IN    A    192.1.1.1
>     foo.bar.baz.    60    IN    A    192.1.1.2
>     foo.bar.baz.    60    IN    A    192.1.1.3

accomplish on a 4.9 or later name server just what the shuffle address records did on a patched 4.8.3 server. The BIND documentation calls this process round robin.

It's a good idea to reduce the records' time-to-live, too, as we did in this example. This ensures that if the addresses are cached on an intermediate name server that doesn't support round robin, they'll time out of the cache quickly. If the intermediate name server looks up the name again, your authoritative name server can round robin the addresses again.

Note that this is really load sharing, not load balancing, since the name server gives out the addresses in a completely deterministic way, without regard to the actual load or capacity of the servers servicing the requests. In our example, the server at address 192.1.1.3 could be a 486DX33 running Linux, and the other two servers HP9000 K420s, and the Linux box would still get a third of the queries. Listing a higher-capacity server's address multiple times won't help, because BIND eliminates duplicate records.

10.11 Securing Your Name Server |  | 11. nslookup